Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-3154/522.txt

Text File | 1992-05-11 | 27KB | 621 lines

Today's Topics:
                        *.doo PICTURE FORMATS
                                 ARJ?
                              Golf sims
Install an app for two diff filetypes, term with IBM graphics option?
                     LHARC 2.01E VS ZOO 2.1: SOME
             lharc 2.01e vs zoo 2.1: some tests (2 msgs)
    People dumping machines (was.. Atari Mega 2 system.. for sale)
                      PEOPLE DUMPING MACHINES...
                        Populous / Powermonger
                 Railroad Tycoon Needs File (2 msgs)
                         SLM804 laser printer
                      Spectre GCR/System 7/A/UX

Welcome to the Info-Atari16 Digest.  The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out.  Please send notifications about broken digests or bogus messages
to [e-mail].

Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
instead of the moderators are likely to be lost or ignored.

If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------

Date: 2 Oct 91 06:24:24 GMT
From: munnari.oz.au!goanna!minyos.xx.rmit.oz.au![e-mail] (Richard
 Clarkson)
Subject: *.doo PICTURE FORMATS
To: [e-mail]

What programs are available that allow one to draw/paint in *.doo picture
formats?

I am chasing a program that does such format!

Many thanks in Advance

Richard Clarkson

------------------------------

Date: 1 Oct 91 14:49:17 GMT
From: noao!asuvax!cs.utexas.edu!convex![e-mail] (William Rosenkranz)
Subject: ARJ?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>In <[e-mail]>, William Rosenkranz writes:
>>pfx is nice. i do use it on occasion. i plan to use it more now that i
>
>What does that mean ? Why do you have to get the source of pfx before you
>pay the shareware fee ??????? DM 20.- (About US$ 12.-) isn't much for a
>powerfull tools like the extended pfxpak+, so why should TQ deliver the
>source. If I write a program, I don't want everybody to extend their own
>programs by including my sourcecode. If you use pfxpak, you have to pay,
>if you want the source, you have to pay more ( I think, TQ will perhaps
>behave like that ).

well, as i explained countless times, although the argument is certainly
weaker with pfx, i don't use any archiver at all unless i have source to
it. i want to insure that i can get at any datafile i have on any future
system i have. with packed executables, this is less of a problem because
they will generally only run on an ST. that is unless i go and load up
the .ttp file with other files as well. so far, i have used pfx on exactly
3 executable files out of hundreds. it does not make even a tiny dent in
my disk usage. i can (and have) disassemble it since it is not that big.
unfortunately, when my system crashed when trying to get lharc to work
with MW/ARGV extended args, it took my ramdisk along with it (where i
had the disassembled source temporarily - VERY temporarily in this case :-).
and no, i do NOT intend to give the disassembled source to anyone. it is
for my own use, for insurance.

i have on occasion, with software i use often, supported shareware. usually
with PC programs (PC write, AM Tax, etc). on the ST there are fortunately
lots of software, with source, where the author or or person doing the port
ask for nothing. i have never asked for a single penny with codes i post
here which i know more than a few people use (nroff, mgif, man/manpager,
etc). nor did the person porting zoo 2.1 for that matter. i have no problems
with people wanting to make a buck for their labor. i just don't tend to use
s/w on the ST that is not either of my own writing, or PD or whatever. and
archivers, for the reasons i outlined, i treat differently than any other
sort of program. when i post code, i generally always post source. and i
place no restrictions on its use at all. i generally don't even include
a copyright. and the code i write ends up in some odd places (nroff became
the text formatter for minix, tho i did not even write it for that purpose,
not do i even have an operational minix system). i just don't care that
minix is distributed (for profit) with one of my codes in source form.

requesting the source, in this case, will save me the time of disassembling
it, correcting the disassembled source, reformatting it, and annotating
it. pfx is small enough that this is no more than a couple hours work so
it is not a big deal. and if i intend to make widespread use of this
program, i WILL disassemble it, and have source anyway. i don't think there
is any law on the books that prohibits me from doing this, especially if
it goes no further than my system, which it won't. it is a simple request
to save me some time. with 80 MB of disk at my disposal, the couple of
MB it will save is not a huge benefit anyway.

i would not disassemble a spreadsheet, database, or any other sort of program.
but for me, archivers are different.

-bill
[e-mail]

--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: [e-mail]

------------------------------

Date: 1 Oct 91 17:41:38 GMT
From: cis.ohio-state.edu!turtle.cis.ohio-state.edu![e-mail]
 (jeffery d thompson)
Subject: Golf sims
To: [e-mail]

A little while ago I bought Jack Nicklaus' Greatest 18 Holes of Golf
and I was wondering if there are any course disks or course builders
available. Any information is greatly appreciated.
                                        Jeff
                                [e-mail]

------------------------------

Date: 1 Oct 91 14:21:18 GMT
From: mcsun!unido!horga!presto![e-mail] (David Channing)
Subject: Install an app for two diff filetypes, term with IBM graphics option?
To: [e-mail]

In article <[e-mail]> [e-mail]
(Ryan 'Gozar' Collins) writes:
>
> 1. Is there anyway to install an application for more than one filetype?
> filetype. Well, it won't let you do that under 1.4 :*(  So I tried to
> edit the desktop.inf file adding the required lines to install the
> application for two filetypes. Well, my ST just crashed on boot up

You must have messed up your desktop.inf file editing it. Here are the
relevant lines from my desktop.inf which works with no problems:

#F FF 04   C:\BIN\ARCLOAD.PRG@ *.ARC@
#F FF 04   C:\BIN\ARCLOAD.PRG@ *.LZH@
#F FF 04   C:\BIN\ARCLOAD.PRG@ *.ZOO@


--
[e-mail]
[e-mail]

------------------------------

Date: 1 Oct 91 16:09:47 GMT
From: noao!asuvax!cs.utexas.edu!convex![e-mail] (William Rosenkranz)
Subject: LHARC 2.01E VS ZOO 2.1: SOME
To: [e-mail]

In article <[e-mail]> [e-mail] (Philip
 Durgin) writes:
>One thing you forgot to take into account, If you optimize your HD before you
>run any of those tests, the amount of time need to add or extract a file is
>significantly different. We use LHarc201d.ttp as part of our Network software.
>We found that many things can change how fast a file may be extracted or added
>to a file. Your test bed is flawed, a strict ram disk would have show a better
>corrilation of the true speed for extracting or adding a file. I will try it on
>our board and upload the differences.

i did not fail to take this into account. i did discuss the HD issue. i
have also pointed out that unless a partition is clean, i very well could
produce wildly differing results if significant i/o takes place. at least
the ramdisk offers equal footing, if you do alot of archive manipulation
in ramdisks (which i do, BTW). i know that this test may not be representative
of many situations, that, in effect, i cancelled i/o from the equation
(which i realize could be EXTREMELY significant). i did mention this, however.
at any rate, the test does point to the actual compression speeds, minimizing
i/o since it is MUCH faster to go to memory than disk.

if i had an empty partition (if i EVER have an empty partition :-) i would
have done the test in both the ramdisk and the HD. i would have compared
the relative speed ratio ramdisk/hd for each program. note that with zoo,
i could also have profiled the code and isolated the routines where most
of the time is spent. i believe bill shroka did that when he ported zoo 2.1.

i look forward to seeing a thorough test, similar to the one i did, but
in HD partitions. just be aware of these potential variables, however:

        - disk access speed (run both with similar disks)

        - disk interleave

        - amount of pre-existing data in the partition and the amount
          of fragmentation. ideally, you want to run these tests in
          the same empty partition.

        - location of temporary files. ideally, and i am not even sure
          this is ideal, you would want the temporary files to be located
          in the same partition as the test. be careful with environment
          variables called "TMP" or "TEMP". if these point to a ramdisk
          and one of the programs use this while the other does not, your
          test is biased. or at least point out that one has this feature
          and the other does not. that would be a signifiant plus, IMHO.

i tried to eliminate all of these by simply working in a ramdisk for the
first cut. i would tend to think that both programs do similar amounts of
i/o, so the program that uses bigger buffers and/or inlined i/o will probably
win. i don't know which one that is.

if you can do this over a network, that would be another interesting
set of datapoints. however, in equal environments, i would expect both codes
to function about the same.

good luck. please post the results...

-bill
[e-mail]



--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: [e-mail]

------------------------------

Date: 1 Oct 91 15:47:27 GMT
From: noao!asuvax!cs.utexas.edu!convex![e-mail] (William Rosenkranz)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: [e-mail]

In article <[e-mail]> [e-mail] (Thomas Quester)
 writes:
>LHarc is only partly written in assembly-language. Some parts

i am sure the parts in assembler are the parts that are highest on the
profile.

zoo does its thing in 100% portable C. the same code i run on a supercomputer
will compile and run on my ST with little if any changes. and it will run
about as fast as lharc and will produce files of similar size.

>of the coder itself are in C. It only is a long hand hard way
>to produce a higly optimzied version of about 1000 lines of
>nearly undocumented source. The rest of the coder and decoder
>will be written in assembly language some times later. It took
>some version to make 1.13 four times faster.

tho i laud your efforts in making (your) lharc scream, i still cannot unpack
lh5 archives on non-atari (eg unix, VMS, etc) systems. it sounds like the
original C for lharc was really bad. i do contend, however, that it would
have been far better to 1) restructure the C, 2) profile the code, isolating
hot spots, 3) find the reason why it is slow and remedy (try inlining,
register variables, -O in gcc, etc), and 4) provide the source. zoo does
exactly that. the changes made to zoo to get it to run and to run fast
are minimal.

>>i tried:
>>
>>        lharc a lll *
>>
>>and my system crashed! lharc does NOT handle extended args. and what's more
>
>It does handle the ARGV, but only up to 200 filenames. I bed
>you to retype your command, maybe someting went wrong earlier.

i did not have 200 file names. more like 15, but longer than the 125 or
so chars Pexec handles. this is obviously a bug in your ARGV which is
appearently not capable of handling MW-style ARGV. zoo (actually GNU C)
ARGV support does.

>>        - nitpicking: zoo lists files one per line. it is easier to grep
>>          things out for more specialized uses (like making lists of all
>>          .c files with their statistics).
>
>Why not use lharc l archiv?

ok, i will. this was a minor detail. with virtually every other archiving
system, the syntax "xxx v archive" gives me one line per file format.
lharc uses 2 lines. it is not consistent with arc and zoo. and it is
a VERY minor detail (nitpicking). i only mention this because i sometimes
do use the archive listing for other purposes than listing it to the
screen. it is not a big deal.

>>        - zoo 2.1 can extract files from ANY zoo archive of equal or
>>          lesser version. older versions of zoo can list any zoo archive
>>          even if made with a newer version. if a newer version is needed
>>          to extract files, the older zoo tells you what version you need.
>
>So Lharc does. It will not say the version number, but give a
>message "unknown method". Though there are some versions of
>LHarc availbe without this test (for example unlzh).

no. some older versions of lharc will die and crash the system on some other
(newer) lharc formats. what i was saying is that zoo 2.01 (?) will list
a zoo 2.1 high compression archive, but it can't extract files, but it
1) tells you the version you need to do so, 2) will not crash. the big
difference is that rahul dhesi takes an active part in zoo. yoshi does not
appear to, at least in the US. and like i've said a zillion times, there is
only one zoo. responsible people doing ports send the changes back to
rahul so he can sanction them and incorporate the changes for the next
release. this, from what i can tell, does not happen with lharc. there are
many, many incompatible lharc programs, as you of course know. that means
there is no standard lharc on every platform. yours may be standard on
the ST, but it is far from universal (like zoo or arc). there are unix
and VMS versions of these. there are none for lharc 2.01e (because of the
assembly language). again, i offer to port it to unix where it may run
slow, but it will at least run. do u understand the differences i try
to point out here? the ST is not the center of the universe with respect
to archivers.

i think if ARJ is as good as people say, then both lharc and zoo will die
anyway. so perhaps i am wasting my time.

-bill
[e-mail]
--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: [e-mail]

------------------------------

Date: 2 Oct 91 02:32:18 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!zaphod.mps.ohio-state.edu!sol.ctr.colu
 mbia.edu!ira.uka.de!THD-News![e-mail] (WALLMANN, GEORG)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: [e-mail]

Following the discussion I tried three archiver programs
to backup 151 files worth 700KB of data. The data consisted
almost entirely of documentation (ASCII) and C source.

Machinery: ST-1MB w/40MB ST-251-1
I did NOT clean my partition for this test, why should I? I
never evacuate any partition just for arcing things up. So
I think this is more true to life, than any more 'scientific'
setup. I did the test twice, which didn't change any of
the timing values significantly and gave every program
a 'fair' chance on a equally fragmented harddisk. Fragmentation
is more of an issue when unpacking anyway.



Results:

ARC 6.02
   Size: 304048 bytes   Time: 3:48

ZOO 2.1
   Size: 307207 bytes   Time: 4:45
after issueing a pack command for an additional 2:20
   Size: 307151 bytes

LHARC 2.01d
   Size: 218964 bytes   Time: 6:13

(my) conclusions:
 So guess what, good old ARC is by far the fastest,
 LHARC is the tightest,
 And ZOO well the -um- most compatible...


And they way I called them (thru make)

#ARC=arc
# update
#UPDATE=u
# update with subdirectories
#DIRUP=uz

#ARC=zoo
# update
#UPDATE=aun:
# update with subdirectories
#DIRUP=aun//

ARC=lharc
# update
UPDATE=u -s -wf:\tmp
# update with subdirectories
DIRUP=u -r2 -p -s -wf:\tmp

GSOURCES=*.h *.c *.tlk *.s *.y make*.* memo

backup:
        $(ARC) $(DIRUP)  arc\backup support doc lib header demo
        $(ARC) $(UPDATE) arc\backup $(GSOURCES)


   Nat!

------------------------------

Date: 1 Oct 91 23:34:21 GMT
From:
 noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
 .ohio-state.edu!usenet.ins.cwru.edu!yfn.ysu.edu!ysub!psuvm!cunyvm!jokhc@arizona
 .edu (Joshua Kronengold)
Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
To: [e-mail]

In article <[e-mail]>, [e-mail]
(Alexander Herzlinger [Informatik]) says:
>
>In article <[e-mail]> [e-mail] (Joshua
>Kronengold) writes:
>....
>>Sorta.  It IS a 32mhz proc in a 16mhz architecture with a cache, but if you
>>have TT-ram, the TT ram is counted as cache.  So most applications that use
the
>>high speed will fit entirely in the 'cache,' acting as if it was a 'true' 32m
z
>>machine.(animation is an exception, but I suspect the Blitter might help with
>>that). So, most of the time it will act faster than the 'true 25mhz 68030'.
>>
>>Someone correct me if I've said anything disasterous.
>Which part of the architecture is based on 16Mhz ? Please be a little more
>specific. TT-Ram is normal ram that is organized 32Bit width and can be
>accessed via burst mode. In my opinion a cache is something different,
>e.g. having a 'syncronized' (sorry I am no technican so this might be the
>wrong word for it) memory like in the ST (or the so called ST-Ram in the TT)
>and this does not let you access more than it is build to. If you want to
>use fast prozessors but have only this type of ram every ram access would be
>slowed down, so you use a small piece of high speed ram (the cache) wich
>maps often access areas of the normal memory.
>But programms running in TT Ram do not need to access ST-Ram (they
>could if they want of course) and therefor run all the time in fast TT-ram.
>So if you speak of 16Mhz Architecture this means for me that parts of the
>computer are slowed down due to some 16Mhz clock. The only thing I can think
>of what is slowed down is the 64Bit width ST-ram bus. There the videologic
>has to access the bus very often so the 68030 has to wait until the video-
>logic has finished their access-cycle.
>So in my eyes the TT has fast TT-Ram and a big video/multipurpose ram
>>hich can be used by programms too, and I do not see any big disadvantages.

>ciao,
>   Alex

>--------------------------------------------------------------------------
>Alexander Herzlinger University of Kaiserslautern
>E-Mail: [e-mail]      correct me if I am wrong
>--------------------------------------------------------------------------
Well, that is what I said, after all, 'has no effect except for animation' and
/o.  I can also see no major disads though it might have an effect on real-time
ni, though, like I said, if the blitter can speed up bit-block transfers, it
might be able to surmount that problem.              ~~~~~~~~~~~~~~~~~~~
                                                     of course it can, I meant
                                                     bettween TT and ST ram.
-------
< Joshua Kronengold<[e-mail]>                            >
< "Oh Lord, what fools these mortals be!"-Robin Goodfellow            >
< "Never underestimate man's potential for stupidity"                 >
<                                       -Woodrow Wilson Smith         >

------------------------------

Date: Wed, 02 Oct 91 21:21:01 SST
From: "S. Suthipuntha" <[e-mail]>
Subject: PEOPLE DUMPING MACHINES...
To: [e-mail]

A close look at the NeXT motherboard I saw a SIM socket not unlike a
                                             ~~~~~~~~~~
socket for the SIM ROM on the Mac IICi. Thus I guess that they probably
                                                          ~~~~~
use 512K 'clean 32-BIT' SIM ROM or at least the 256K Mac SE30 SIM ROMs.
How these SIM ROM can be obtained is yet remain to be seen.

Just to clearify these 2 points. These SIM socket on NeXT motherboard is an
empty socket of extra SIM  not the NeXT OS ROMs.

they refer to those who are now writing the Mac Emulator at MIT not the NeXT
~~~~
computer.

I am wondering when Dave Small's will start worrking on the Spectre 256.

Bye,

S. Suthipuntha, School of Architecture, National University of Singapore
                [e-mail]

------------------------------

Date: 2 Oct 91 11:36:26 GMT
From: mcsun!uknet!ukc!bcc.ac.uk![e-mail] (Mr Stephen R Usher)
Subject: Populous / Powermonger
To: [e-mail]

1) Yes Populous does work on the STe (and on the TT if you turn off the sound
        within the game as soon as it starts).
2) I don't know.

Steve

Addresses:-
JANET   [e-mail]       or      [e-mail]@uk.ac.uknet
Internet
        [e-mail]       or      [e-mail]@uknet.ac.uk

------------------------------

Date: 1 Oct 91 16:02:12 GMT
From:
 noao!ncar!asuvax!cs.utexas.edu!wupost!micro-heart-of-gold.mit.edu!bloom-beacon!
 eru!hagbard!sunic!chalmers.se!dtek.chalmers.se![e-mail] (Per Anders
 Olausson)
Subject: Railroad Tycoon Needs File
To: [e-mail]

[e-mail] (David G. Adams) writes:

>I just recieved Railroad Tycoon from Sideline Software (Friday to be exact).

>Problem.  The install program choked when it couldn't find the file named
>COLOUR.LBM.  I talked to Sideline (They're not at fault in anyway) and the
>representative said he had the file and I'd need to mail him my disks so he
>could copy the file to them and mail them back.  Big long time spent in
>transit over the country (Albuquerque to Ft. Lauderdale and back).

  I, too, experienced this problem when trying to run it on a hard disk.

  In order to fix this I just copied first disk one and then disk two to
  the directory on the hard disk. When doing disk 2 it asked me if I wanted
  to overwrite the files present (which came from disk one) and this I did.

  Naturally you wonder if the dupes on the disk were important but I've been
  playing the game for a week now and it didn't seem to do any harm.

  pao


--
.............................Andrew Olausson................................
............................Systems Architect...............................
[e-mail]............................
[e-mail].................................

 ------------------------------

Date: 1 Oct 91 16:06:35 GMT
From:
 noao!ncar!asuvax!cs.utexas.edu!wupost!micro-heart-of-gold.mit.edu!bloom-beacon!
 eru!hagbard!sunic!chalmers.se!dtek.chalmers.se![e-mail] (Per Anders
 Olausson)
Subject: Railroad Tycoon Needs File
To: [e-mail]

[e-mail] (Roger Sheppard) writes:

>But the chap that wrote the article in ST-Report suggests that all
>owners of Railroad Tycoon send there disks back and ask for there
>money back, he states that there are far to many Bugs in ST the port
>of this game..

  There is a lot of bugs present when you have lost a game etc but I still
  haven't found myself trapped when *in* the game.

  In other words I don't think the external bugs have any counterparts when
  running the game itself.

  It sure is the first buggy Microphrose game I've owned anyway and I don't
  like it at all, they used to produce stuff that were better tested than this.

  pao

--
.............................Andrew Olausson................................
............................Systems Architect...............................
[e-mail]............................
[e-mail].................................

------------------------------

Date: 2 Oct 91 08:14:56 GMT
From:
 noao!asuvax!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!news.claremont.edu!jarthur
 .claremont.edu![e-mail] (Dan Crevier)
Subject: SLM804 laser printer
To: [e-mail]

I recently got a SLM804 Atari laser printer, and I have a few questions.

1. Using Pagestream 1.8 (I don't have the money to upgrade at the present),
I cannot get it to print with the DMA version, but the other version using
the Diablo emulator works.  However, selecting manual feed does not seem to
have any effect.  I have used the manual feed in Ultrascript sucessfully, so
I know it is a problem in the SLM drivers in Pagestream, not something I am
doing wrong.  I can always output the files into a disk file as postscript
and then print them out with Ultrascript, but it would be much more
convenient to print directly.  Does anyone know if there is a newer SLM
printer driver for pagestream?  Mine say beta version.

2. I purchased Ultrascript, and it has a folder called NUFONTS that contains
files with extensions .QFM and .OTL.  It never mentions the existance of
this folder, or of these file types in the manual?  What are they?  Also,
does Ultrascript replace Tymes-Roman with Lucida normally?  If not, can it
be made to?

Thanks

Dan

------------------------------

Date: 2 Oct 91 19:19:01 GMT
From: aahs.no![e-mail] (Karl Anders 0ygard)
Subject: Spectre GCR/System 7/A/UX
To: [e-mail]

1 simple question: Does Spectre run System 7 and A/UX?

Karl Anders Oygard - Karl A Oygard <[e-mail]>

------------------------------

End of Info-Atari16 Digest
******************************